home *** CD-ROM | disk | FTP | other *** search
-
-
-
- CI User Commands CI
-
-
-
- NNAAMMEE
- ci - check in RCS revisions
-
- SSYYNNOOPPSSIISS
- ccii [ options ] file ...
-
- DDEESSCCRRIIPPTTIIOONN
- _C_i stores new revisions into RCS files. Each file name end-
- ing in `,v' is taken to be an RCS file, all others are
- assumed to be working files containing new revisions. _C_i
- deposits the contents of each working file into the
- corresponding RCS file.
-
- Pairs of RCS files and working files may be specified in 3
- ways (see also the example section of _c_o (1)).
-
- 1) Both the RCS file and the working file are given. The RCS
- file name is of the form _p_a_t_h_1/_w_o_r_k_f_i_l_e,v and the working
- file name is of the form _p_a_t_h_2/_w_o_r_k_f_i_l_e, where _p_a_t_h_1/ and
- _p_a_t_h_2/ are (possibly different or empty) paths and _w_o_r_k_f_i_l_e
- is a file name.
-
- 2) Only the RCS file is given. Then the working file is
- assumed to be in the current directory and its name is
- derived from the name of the RCS file by removing _p_a_t_h_1/ and
- the suffix `,v'.
-
- 3) Only the working file is given. Then the name of the RCS
- file is derived from the name of the working file by remov-
- ing _p_a_t_h_2/ and appending the suffix `,v'.
-
- If the RCS file is omitted or specified without a path, then
- _c_i looks for the RCS file first in the directory ./RCS and
- then in the current directory.
-
- For _c_i to work, the caller's login must be on the access
- list, except if the access list is empty or the caller is
- the superuser or the owner of the file. To append a new
- revision to an existing branch, the tip revision on that
- branch must be locked by the caller. Otherwise, only a new
- branch can be created. This restriction is not enforced for
- the owner of the file, unless locking is set to _s_t_r_i_c_t (see
- _r_c_s (1)). A lock held by someone else may be broken with
- the _r_c_s command.
-
- Normally, _c_i checks whether the revision to be deposited is
- different from the preceding one. If it is not different, _c_i
- either aborts the deposit (if --qq is given) or asks whether
- to abort (if --qq is omitted). A deposit can be forced with
- the --ff option.
-
- For each revision deposited, _c_i prompts for a log message.
-
-
-
- Purdue University 6/29/83 1
-
-
-
-
-
-
- CI User Commands CI
-
-
-
- The log message should summarize the change and must be ter-
- minated with a line containing a single `.' or a control-D.
- If several files are checked in, _c_i asks whether to reuse
- the previous log message. If the std. input is not a termi-
- nal, _c_i suppresses the prompt and uses the same log message
- for all files. See also --mm.
-
- The number of the deposited revision can be given by any of
- the options --rr, --ff, --kk, --ll, --uu, or --qq (see --rr).
-
- If the RCS file does not exist, _c_i creates it and deposits
- the contents of the working file as the initial revision
- (default number: 1.1). The access list is initialized to
- empty. Instead of the log message, _c_i requests descriptive
- text (see --tt below).
-
- --rr[_r_e_v] assigns the revision number _r_e_v to the checked-in
- revision, releases the corresponding lock, and
- deletes the working file. This is also the
- default.
-
- If _r_e_v is omitted, _c_i derives the new revision
- number from the caller's last lock. If the caller
- has locked the tip revision of a branch, the new
- revision is appended to that branch. The new revi-
- sion number is obtained by incrementing the tip
- revision number. If the caller locked a non-tip
- revision, a new branch is started at that revision
- by incrementing the highest branch number at that
- revision. The default initial branch and level
- numbers are 1. If the caller holds no lock, but
- he is the owner of the file and locking is not set
- to _s_t_r_i_c_t, then the revision is appended to the
- trunk.
-
- If _r_e_v indicates a revision number, it must be
- higher than the latest one on the branch to which
- _r_e_v belongs, or must start a new branch.
-
- If _r_e_v indicates a branch instead of a revision,
- the new revision is appended to that branch. The
- level number is obtained by incrementing the tip
- revision number of that branch. If _r_e_v indicates
- a non-existing branch, that branch is created with
- the initial revision numbered _r_e_v._1.
-
- Exception: On the trunk, revisions can be appended
- to the end, but not inserted.
-
- --ff[_r_e_v] forces a deposit; the new revision is deposited
- even it is not different from the preceding one.
-
-
-
-
- Purdue University 6/29/83 2
-
-
-
-
-
-
- CI User Commands CI
-
-
-
- --kk[_r_e_v] searches the working file for keyword values to
- determine its revision number, creation date,
- author, and state (see _c_o (1)), and assigns these
- values to the deposited revision, rather than com-
- puting them locally. A revision number given by a
- command option overrides the number in the working
- file. This option is useful for software distri-
- bution. A revision that is sent to several sites
- should be checked in with the --kk option at these
- sites to preserve its original number, date,
- author, and state.
-
- --ll[_r_e_v] works like --rr, except it performs an additional _c_o
- -_l for the deposited revision. Thus, the deposited
- revision is immediately checked out again and
- locked. This is useful for saving a revision
- although one wants to continue editing it after
- the checkin.
-
- --uu[_r_e_v] works like --ll, except that the deposited revision
- is not locked. This is useful if one wants to
- process (e.g., compile) the revision immediately
- after checkin.
-
- --qq[_r_e_v] quiet mode; diagnostic output is not printed. A
- revision that is not different from the preceding
- one is not deposited, unless --ff is given.
-
- --mm_m_s_g uses the string _m_s_g as the log message for all
- revisions checked in.
-
- --nn_n_a_m_e assigns the symbolic name _n_a_m_e to the number of
- the checked-in revision. _C_i prints an error mes-
- sage if _n_a_m_e is already assigned to another
- number.
-
- --NN_n_a_m_e same as --nn, except that it overrides a previous
- assignment of _n_a_m_e.
-
- --ss_s_t_a_t_e sets the state of the checked-in revision to the
- identifier _s_t_a_t_e. The default is _E_x_p.
-
- --tt[_t_x_t_f_i_l_e]
- writes descriptive text into the RCS file (deletes
- the existing text). If _t_x_t_f_i_l_e is omitted, _c_i
- prompts the user for text supplied from the std.
- input, terminated with a line containing a single
- `.' or control-D. Otherwise, the descriptive text
- is copied from the file _t_x_t_f_i_l_e. During initiali-
- zation, descriptive text is requested even if --tt
- is not given. The prompt is suppressed if std.
- input is not a terminal.
-
-
-
- Purdue University 6/29/83 3
-
-
-
-
-
-
- CI User Commands CI
-
-
-
- DDIIAAGGNNOOSSTTIICCSS
- For each revision, _c_i prints the RCS file, the working file,
- and the number of both the deposited and the preceding revi-
- sion. The exit status always refers to the last file
- checked in, and is 0 if the operation was successful, 1 oth-
- erwise.
-
- FFIILLEE MMOODDEESS
- An RCS file created by _c_i inherits the read and execute per-
- missions from the working file. If the RCS file exists
- already, _c_i preserves its read and execute permissions. _C_i
- always turns off all write permissions of RCS files.
-
- FFIILLEESS
- The caller of the command must have read/write permission
- for the directories containing the RCS file and the working
- file, and read permission for the RCS file itself. A number
- of temporary files are created. A semaphore file is created
- in the directory containing the RCS file. _C_i always creates
- a new RCS file and unlinks the old one. This strategy makes
- links to RCS files useless.
-
- IIDDEENNTTIIFFIICCAATTIIOONN
- Author: Walter F. Tichy, Purdue University, West Lafayette,
- IN, 47907.
- Revision Number: 3.1 ; Release Date: 83/04/04 .
- Copyright (C) 1982 by Walter F. Tichy.
-
- SSEEEE AALLSSOO
- co (1), ident(1), rcs (1), rcsdiff (1), rcsintro (1),
- rcsmerge (1), rlog (1), rcsfile (5), sccstorcs (8).
- Walter F. Tichy, "Design, Implementation, and Evaluation of
- a Revision Control System," in _P_r_o_c_e_e_d_i_n_g_s _o_f _t_h_e _6_t_h _I_n_t_e_r_-
- _n_a_t_i_o_n_a_l _C_o_n_f_e_r_e_n_c_e _o_n _S_o_f_t_w_a_r_e _E_n_g_i_n_e_e_r_i_n_g, IEEE, Tokyo,
- Sept. 1982.
-
- BBUUGGSS
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Purdue University 6/29/83 4
-
-
-
-
-
-
-